home *** CD-ROM | disk | FTP | other *** search
/ Halting the Hacker - A P…uide to Computer Security / Halting the Hacker - A Practical Guide to Computer Security.iso / rfc / rfc1572.txt < prev    next >
Text File  |  1997-04-01  |  15KB  |  395 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                               S. Alexander, Editor
  8. Request for Comments: 1572                      Lachman Technology, Inc.
  9. Category: Standards Track                                   January 1994
  10.  
  11.  
  12.                        Telnet Environment Option
  13.  
  14. Status of this Memo
  15.  
  16.    This document specifies an Internet standards track protocol for the
  17.    Internet community, and requests discussion and suggestions for
  18.    improvements.  Please refer to the current edition of the "Internet
  19.    Official Protocol Standards" (STD 1) for the standardization state
  20.    and status of this protocol.  Distribution of this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    This document specifies a mechanism for passing environment
  25.    information between a telnet client and server.  Use of this
  26.    mechanism enables a telnet user to propagate configuration
  27.    information to a remote host when connecting.
  28.  
  29.    This document corrects some errors in [1].
  30.  
  31. 1.  Command Names and Codes
  32.  
  33.       NEW-ENVIRON     39
  34.           IS               0
  35.           SEND             1
  36.           INFO             2
  37.  
  38.           VAR              0
  39.           VALUE            1
  40.           ESC              2
  41.           USERVAR          3
  42.  
  43. 2.  Command Meanings
  44.  
  45.    IAC WILL NEW-ENVIRON
  46.  
  47.       The sender of this command is willing to send environment
  48.       variables.
  49.  
  50.    IAC WONT NEW-ENVIRON
  51.  
  52.       The sender of this command refuses to send environment variables.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Telnet Working Group                                            [Page 1]
  59.  
  60. RFC 1572               Telnet Environment Option            January 1994
  61.  
  62.  
  63.    IAC DO NEW-ENVIRON
  64.  
  65.       The sender of this command is willing to receive environment
  66.       variables.
  67.  
  68.    IAC DONT NEW-ENVIRON
  69.  
  70.       The sender of this command refuses to accept environment
  71.       variables.
  72.  
  73.    IAC SB NEW-ENVIRON SEND [ type ... [ type ... [ ... ] ] ] IAC SE
  74.  
  75.       The sender of this command requests that the remote side send its
  76.       environment variables.  The "type" may be either VAR or USERVAR,
  77.       to indicate either well known or user variable names.  Only the
  78.       side that is DO NEW-ENVIRON may initiate a SEND command.  If a
  79.       list of variables is specified, then only those variables should
  80.       be sent.  If no list is specified, then the default environment,
  81.       of both well known and user defined variables, should be sent.  If
  82.       one of the variables has no name, then all the variables of that
  83.       type (well known or user defined)  in the default environment
  84.       should be sent.
  85.  
  86.    IAC SB NEW-ENVIRON IS type ... [ VALUE ... ] [ type ... [ VALUE ... ]
  87.    [ ... ] ] IAC SE
  88.  
  89.       The sender of this command is sending environment variables.  This
  90.       command is sent in response to a SEND request.  Only the side that
  91.       is WILL NEW-ENVIRON may send an IS command.  The "type"/VALUE
  92.       pairs must be returned in the same order as the SEND request
  93.       specified them, and there must be a response for each "type ..."
  94.       explicitly requested.  The "type" will be VAR or USERVAR.
  95.       Multiple environment variables may be sent.  The characters
  96.       following a "type" up to the next "type" or VALUE specify the
  97.       variable name.  The characters following a VALUE up to the next
  98.       "type" specify the value of the variable.  If a "type" is not
  99.       followed by a VALUE (e.g., by another VAR, USERVAR, or IAC SE)
  100.       then that variable is undefined.  If a VALUE is immediately
  101.       followed by a "type" or IAC, then the variable is defined, but has
  102.       no value.  If an IAC is contained between the IS and the IAC SE,
  103.       it must be sent as IAC IAC.  If a variable or a value contains a
  104.       VAR, it must be sent as ESC VAR.  If a variable or a value
  105.       contains a USERVAR, it must be sent as ESC USERVAR.  If a variable
  106.       or a value contains a VALUE, it must be sent as ESC VALUE.  If a
  107.       variable or a value contains an ESC, it must be sent as ESC ESC.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Telnet Working Group                                            [Page 2]
  115.  
  116. RFC 1572               Telnet Environment Option            January 1994
  117.  
  118.  
  119.    IAC SB NEW-ENVIRON INFO type ... [ VALUE ... ] [ type ... [ VALUE ...
  120.    ] [ ... ] ] IAC SE
  121.  
  122.       The sender of this command is sending information about
  123.       environment variables that have changed.  It is identical to the
  124.       IS command, except that the command is INFO instead of IS.  Only
  125.       the side that is WILL NEW-ENVIRON may send an INFO command.  The
  126.       INFO command is not to be used to send initial information; the
  127.       SEND/IS sequence is to be used for that.  The INFO command is to
  128.       be used to propagate changes in environment variables, and may be
  129.       spontaneously generated.
  130.  
  131. 3.  Default Specification
  132.  
  133.    The default specification for this option is
  134.  
  135.       WONT NEW-ENVIRON
  136.       DONT NEW-ENVIRON
  137.  
  138.    meaning there will not be any exchange of environment information.
  139.  
  140. 4.  Motivation
  141.  
  142.    Many operating systems have startup information and environment
  143.    variables that contain information that should be propagated to
  144.    remote machines when Telnet connections are established.  Rather than
  145.    create a new Telnet option each time someone comes up with some new
  146.    information that they need propagated through a Telnet session, but
  147.    that the Telnet session itself doesn't really need to know about,
  148.    this generic information option can be used.
  149.  
  150. 5.  Well Known Variables
  151.  
  152.    USER        This variable is used to transmit the user or account
  153.                name that the client wishes to log into on the remote
  154.                system.  The format of the value the USER variable is
  155.                system dependent, as determined by the remote system.
  156.  
  157.    JOB         This variable is used to transmit the job ID that the
  158.                client wishes to use when logging into the remote system.
  159.                The format of the value the JOB variable is system
  160.                dependent, as determined by the remote system.
  161.  
  162.    ACCT        This variable is used to transmit the account ID that the
  163.                client wishes to use when logging into the remote system.
  164.                The format of the value the ACCT variable is system
  165.                dependent, as determined by the remote system.
  166.  
  167.  
  168.  
  169.  
  170. Telnet Working Group                                            [Page 3]
  171.  
  172. RFC 1572               Telnet Environment Option            January 1994
  173.  
  174.  
  175.    PRINTER     This variable is used to identify the default location
  176.                for printer output.  Because there does not currently
  177.                exist a standard way of naming a printer on a network,
  178.                the format of this variable is currently undefined.
  179.  
  180.    SYSTEMTYPE  This is used to transmit the type of operating system on
  181.                the system that sends this variable.  It value is
  182.                identical to the value of the SYSTEM (SYST) command in
  183.                FTP [4].  The format of the value shall have as its first
  184.                word one of the system names listed in the current
  185.                version of the Assigned Numbers document [5].
  186.  
  187.    DISPLAY     This variable is used to transmit the X display location
  188.                of the client.  The format for the value of the DISPLAY
  189.                variable is:
  190.  
  191.                   <host>:<dispnum>[.<screennum>]
  192.  
  193.                This information is identical to the information passed
  194.                using the Telnet X-DISPLAY-LOCATION option.  If both the
  195.                DISPLAY environment variable, and the X-DISPLAY-LOCATION
  196.                option [6] are received, and they contain conflicting
  197.                information, the most recently received information
  198.                received should be used.
  199.  
  200.    Because it is impossible to anticipate all variables that users may
  201.    wish to exchange, the USERVAR type is provided to allow users to
  202.    transmit arbitrary variable/value pairs.  The use of an additional
  203.    type allows implementations to distinguish between values derived by
  204.    the remote host software and values supplied by the user.  Paranoid
  205.    implementations will most likely treat both types with an equal level
  206.    of distrust.  The results of a name-space collision between a well-
  207.    known and a user variable are implementation specific.
  208.  
  209. 6.  Implementation Rules
  210.  
  211.    WILL and DO are used only at the beginning of the connection to
  212.    obtain and grant permission for future negotiations.
  213.  
  214.    Once the two hosts have exchanged a WILL and a DO, the sender of the
  215.    DO NEW-ENVIRON is free to request that environment variables be sent.
  216.    Only the sender of the DO may send requests (IAC SB NEW-ENVIRON SEND
  217.    IAC SE) and only the sender of the WILL may transmit actual
  218.    environment information (via the IAC SB NEW-ENVIRON IS ... IAC SE
  219.    command).  Though this option may be used at any time throughout the
  220.    life of the telnet connection, the exchange of environment
  221.    information will usually happen at the startup of the connection.
  222.    This is because many operating systems only have mechanisms for
  223.  
  224.  
  225.  
  226. Telnet Working Group                                            [Page 4]
  227.  
  228. RFC 1572               Telnet Environment Option            January 1994
  229.  
  230.  
  231.    propagating environment information at process creation, so the
  232.    information is needed before the user logs in.
  233.  
  234.    The receiving host is not required to put all variables that it
  235.    receives into the environment.  For example, if the client should
  236.    send across USERVAR "TERM" VALUE "xterm" as an environment variable,
  237.    and the TERMINAL-TYPE [3] option has already been used to determine
  238.    the terminal type, the server may safely ignore the TERM variable.
  239.    Also, some startup information may be used in other ways; for
  240.    example, the values for "USER", "ACCT" and "PROJ" values might be
  241.    used to decide which account to log into, and might never be put into
  242.    the users environment.  In general, if the server has already
  243.    determined the value of an environment variable by some more accurate
  244.    means, or if it does not understand a variable name, it may ignore
  245.    the value sent in the NEW-ENVIRON option.  The server may also prefer
  246.    to just put all unknown information into the users environment.  This
  247.    is the suggested method of implementation, because it allows the user
  248.    the most flexibility.
  249.  
  250.    The following is an example of use of the option:
  251.  
  252.        Host1                            Host2
  253.        IAC DO NEW-ENVIRON
  254.                                         IAC WILL NEW-ENVIRON
  255.        [ Host1 is now free to request environment information ]
  256.        IAC SB NEW-ENVIRON SEND VAR
  257.        "USER" VAR "ACCT" VAR USERVAR
  258.        IAC SE
  259.        [ The server has now explicitly asked for the USER and ACCT
  260.          variables, the default set of well known environment variables,
  261.          and the default set of user defined variables.  Note that the
  262.          client includes the USER information twice; once because it was
  263.          explicitly asked for, and once because it is part of the
  264.          default environment.  ]
  265.                                         IAC SB NEW-ENVIRON IS VAR "USER"
  266.                                         VALUE "joe" VAR "ACCT" VALUE
  267.                                         "kernel" VAR "USER" VALUE "joe"
  268.                                         VAR "DISPLAY" VALUE "foo:0.0"
  269.                                         USERVAR "SHELL" VALUE "/bin/csh"
  270.                                         IAC SE
  271.  
  272.    It is legal for a client to respond with an empty environment (no
  273.    data between the IAC SB and IAC SE) when no well-defined or user
  274.    variables are currently defined.  For example:
  275.  
  276.       IAC SB NEW-ENVIRON IS IAC SE
  277.  
  278.    is a valid response to any of the following:
  279.  
  280.  
  281.  
  282. Telnet Working Group                                            [Page 5]
  283.  
  284. RFC 1572               Telnet Environment Option            January 1994
  285.  
  286.  
  287.       IAC SB NEW-ENVIRON SEND IAC SE
  288.       IAC SB NEW-ENVIRON SEND VAR IAC SE
  289.       IAC SB NEW-ENVIRON SEND USERVAR IAC SE
  290.       IAC SB NEW-ENVIRON SEND VAR USERVAR IAC SE
  291.  
  292.    (The last example is equivalent to the first...)
  293.  
  294.    The earlier version of this specification [1] incorrectly reversed
  295.    the values for VAR and VALUE,  which put the specification at odds
  296.    with existing implementations.  In order to resolve that problem, as
  297.    well as other minor problems, a new option number has been assigned
  298.    to the NEW-ENVIRON option.  This allows implementations of this memo
  299.    to interoperate with no ambiguity.
  300.  
  301.    For a discussion on how to implement to interoperate with the various
  302.    implementations that pre-date this memo, see [2].
  303.  
  304.    It is expected that any implementation that supports the Telnet NEW-
  305.    ENVIRON option will support all of this specification.
  306.  
  307. 7.  Security Concerns
  308.  
  309.    It is important for an implementor of the NEW-ENVIRON option to
  310.    understand the interaction of setting options and the
  311.    login/authentication process. Specifically careful analysis should be
  312.    done to determine which variables are "safe" to set prior to having
  313.    the client login.  An example of a bad choice would be permitting a
  314.    variable to be changed that allows an intruder to circumvent or
  315.    compromise the login/authentication program itself.
  316.  
  317. 8.  References
  318.  
  319.    [1] Borman, D., Editor, "Telnet Environment Option", RFC 1408, Cray
  320.        Research, Inc., January 1993.
  321.  
  322.    [2] Borman, D., "Telnet Environment Option Interoperability Issues",
  323.        RFC 1571, Cray Research, Inc., January 1994.
  324.  
  325.    [3] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091, FTP
  326.        Software, Inc., February 1989.
  327.  
  328.    [4] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD
  329.        9, RFC 959, USC/Information Sciences Institute, October 1985.
  330.  
  331.    [5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
  332.        USC/Information Sciences Institute, July 1992.
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Telnet Working Group                                            [Page 6]
  339.  
  340. RFC 1572               Telnet Environment Option            January 1994
  341.  
  342.  
  343.    [6] Marcy, G., "Telnet X Display Location Option", RFC 1096, Carnegie
  344.        Mellon University, March 1989.
  345.  
  346. Acknowledgements
  347.  
  348.    The original version of this document was written by Dave Borman of
  349.    Cray Research, Inc.  In addition, the comments of the Telnet Working
  350.    Group of the IETF are gratefully acknowledged.
  351.  
  352. Security Considerations
  353.  
  354.    Security issues are discussed in Section 7.
  355.  
  356. Editor's Address
  357.  
  358.    Steve Alexander
  359.    Lachman Technology, Inc.
  360.    1901 North Naper Boulevard
  361.    Naperville, IL 60563-8895
  362.  
  363.    Phone: (708) 505-9555 x256
  364.    EMail: stevea@lachman.com
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Telnet Working Group                                            [Page 7]
  395.